home *** CD-ROM | disk | FTP | other *** search
- Path: lyra.csx.cam.ac.uk!nmm1
- From: nmm1@cus.cam.ac.uk (Nick Maclaren)
- Newsgroups: comp.std.c,comp.arch.arithmetic,sci.math.num-analysis
- Subject: Re: Why is <float.h>? [was Re: sizeof(1L) in preprocesor ...]
- Date: 12 Jan 1996 10:36:58 GMT
- Organization: University of Cambridge, England
- Distribution: inet
- Message-ID: <4d5dka$iua@lyra.csx.cam.ac.uk>
- References: <sc3f9vb6gk.fsf@lns101.lns.cornell.edu> <4ctk66$57j@lyra.csx.cam.ac.uk> <KANZE.96Jan9135752@slsvewt.lts.sel.alcatel.de> <4ctpkv$82v@lyra.csx.cam.ac.uk> <4d1hh7$kd@lyra.csx.cam.ac.uk> <4d4fgb$22d@usenet.pa.dec.com>
- NNTP-Posting-Host: ursa.cus.cam.ac.uk
-
- In article <4d4fgb$22d@usenet.pa.dec.com>, diamond@tko.dec.com (Norman Diamond) writes:
- |> In article <4d1hh7$kd@lyra.csx.cam.ac.uk>, nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
- |> >Numerical analysts use values of the sort that are found in <float.h>
- |> >for many purposes, including:
- |> > 1) Switching to alternate algorithms for special functions.
- |> > 2) Avoiding overflow, underflow and rounding error.
- |> > 3) Selecting appropriate precisions for conversion on I/O.
- |> > 4) Varying the algorithm in the rare cases where it matters.
- |> >Now, (1) needs the values to be preprocessor constants for efficiency.
- |> >Remember that such people are the very people who write the functions
- |> >called via <math.h>, and we like to be able to write code that compiles
- |> >automatically and correctly even on machines that we have never heard
- |> >of! But to do this efficiently, we have to define our OWN <float.h>,
- |> >which isn't portable!
- |>
- |> No, for (1), you do not need to define your own <float.h>. You need
- |> to address two categories:
- |>
- |> (A) Implementations where definitions in <float.h> are preprocessor
- |> constants. You can write one version of your code using #if directives
- |> as necessary, presuming that these are preprocessor constants, and your
- |> code will work under all such implementations.
- |>
- |> (B) Implementations where definitions in <float.h> are not preprocessor
- |> constants. .... You can write one version of
- |> your code using if statements as necessary, without presuming that these
- |> are preprocessor constants, and your code will work under all implementations.
- |>
- |> You might want to provide just one version with additional #if directives
- |> to choose between version (A) for efficiency and (B) for reliability.
-
- I am afraid not. Here is a sample of the problems:
-
- 1) You are proposing writing two separate libraries, which is
- 3-4 times the work of writing one, assuming that you want to keep
- them 100% compatible.
- 2) Many versions of <float.h> have SOME values as pre-processor
- constants and others as general rvalues (e.g. Solaris 2).
- 3) You have to allow for the case where the values are constants,
- but not pre-processor constants.
- 4) There is no portable way to test whether (A) or (B) is true,
- let alone whether you have an intermediate case.
-
- Remember that the semantic rules for the evaluation of preprocessor
- expressions are not the same as those for compile-time constant
- expressions, which are not the same as those for run-time ones.
-
- Also, remember that I am into REAL portability - i.e. I write code
- that is expected to work on hardware and under an operating system
- and compiler that I had never heard of when I was writing the code.
- And I don't just mean UNIX-like ones.
-
- My point was never that it cannot be done - I have been doing it
- for 25 years. My point is that <float.h> is almost useless for
- much or most numerical code.
-
-
- Nick Maclaren,
- University of Cambridge Computer Laboratory,
- New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
- Email: nmm1@cam.ac.uk
- Tel.: +44 1223 334761 Fax: +44 1223 334679
-
-
-